A dynamic system (either natural or man-made) is a system whose response at any given time is a function of its input stimuli, its current state, and the current time. Such systems range from simple to highly complex. Physical examples of dynamic systems include a falling body, the rotation of the earth, bio-mechanical systems (muscles, joints, etc.), bio-chemical systems (gene expression, protein pathways), weather and climate pattern systems, etc. Examples of man-made or engineered dynamic systems include: a bouncing ball, a spring with a mass tied to an end, automobiles, airplanes, control systems in major appliances, communication networks, audio signal processing, nuclear reactors, a stock market, etc. Professionals from diverse areas such as engineering, science, education, and economics build mathematical models of dynamic systems in order to better understand system behavior as it changes with the progression of time. The mathematical models aid in building better systems, where “better” may be defined in terms of a variety of performance measures such as quality, time-to-market, cost, speed, size, power consumption, robustness, etc. The mathematical models also aid in analyzing, debugging and repairing existing systems (be it the human body or the anti-lock braking system in a car). The models may also serve an educational purpose of educating others on the basic principles governing physical systems. The models and results are often used as a scientific communication medium between people.
Historically, engineers and scientists have utilized time-based block diagram models in numerous scientific and engineering areas such as Feedback Control Theory and Signal Processing to study, design, debug, and refine dynamic systems. Dynamic systems, which are characterized by the fact that their behaviors change over time, are representative of many real-world systems. Time-based graphical modeling has become particularly attractive over the past years with the advent of software packages, such as Simulink®. Such packages provide sophisticated software platforms with a rich suite of support tools that make the analysis and design of dynamic systems efficient, methodical and cost-effective.
In contrast, state-based and flow diagram modeling environments, such as Stateflow®, are useful to model event-driven systems. State-based environments provide graphical design and development tools for modeling and simulating event-driven systems and subsystems. State diagramming environments describe complex system behavior using state diagrams, which include both logic and internal data and can be used to visually depict a current state during the operation of the system being modeled. The state-based and flow diagram modeling environments provide a graphical design and development tool for describing complex system behavior using finite state machine theory, truth tables, flow diagram notations, and state-transition diagrams. State diagramming environments may enable users to graphically represent hierarchical and parallel states of systems and event-driven transitions between states.
Within conventional graphical modeling environments, a variable that is hierarchical in scope is usually persistent, meaning that it exists from one invocation to the next and retains its value from one invocation to the next. Users of state diagramming environments and time-based graphical modeling environments often use different terms. For a state diagram a hierarchically scoped variable may be a state variable and an invocation may be a “wake-up” of a chart. For some time-based graphical modeling environments a variable may be a digital system memory variable and an invocation may be an execution of the model. Within block diagramming environments a variable that is not hierarchical in scope is typically not persistent. It is volatile and may not exist between invocations or retain its value from one invocation to the next. Block diagramming environments may, be unduly constrained by linking persistence to scope. If a user would like a hierarchically scoped variable to revert to a particular value for each invocation, then the user must insert blocks or code to manually assign the particular value to the variable before it is first accessed during an invocation. In complicated block diagrams, determining where to initialize the hierarchically scoped variable may not be simple or straightforward.